Transaction execution systems which enable the performance of transactions, such as cash issuance at terminals remote from and in communication with a host data processing system having a central data base in which account and other information is stored, are well known. Examples of such systems are provided by or referred to in U.S. Pat. No. 3,956,615 of Anderson, et al, U.S. Pat. No. 3,970,992 of Boothroyd, et al, U.S. Pat. No. 3,937,925 of Boothroyd, U.S. Pat. No. 4,186,871 Anderson, et al, and a copending application of Anderson, et al, Ser. No. 009,384, filed Feb. 2, 1979, entitled Transaction Execution System Having Keyboard and Message Customization, Improved Key Function Versatility and Message Segmentation.
Such systems, which are frequently used by banks to extend their services during times of heavy business or business closure, permit the issuance of cash or the receipt of deposits through a terminal. Such a terminal typically includes a mechanism for receiving and reading information from a credit card, a keyboard, a display and document entry and exit apertures. The terminal may operate in conjunction with a data base or as a stand-alone unit. Increased security for the issuance of cash or the performance of other banking transactions without intervention of a bank employee is attained by issuing a personal ID number with each credit card. A credit card transaction is then enabled only when an ID number corresponding to the account number read from the credit card is entered through the keyboard. This required correspondence prevents a thief or mere finder of a credit card from receiving cash, for example, from a terminal. If a terminal operates in conjunction with a data base, the correspondence between account numbers and ID numbers can be chosen at random, but frequently the ID number is derivable from the account number in accordance with a predetermined code. The former situation will be discussed hereafter. In the latter situation, in order for the ID number to be chosen at random, such as by selection by the customer, an offset value is recorded on the card along with the account number, which offset value is selected such that when added or otherwise combined with the ID number derived from the account number in accordance with the predetermined code, the result is the ID number chosen at random. These predetermined relationships between ID number and account (and offset) data from the card permit a stand-alone terminal to check the ID number by algorithmically relating the ID number to the account number. If credit cards issued by a plurality of cooperating banks are to be usable in a given terminal, all such banks must use the same code or algorithm, or otherwise provide for distinguishing the algorithmic relationship used in issuing ID numbers from account data. In one such system, a key-driven algorithm is provided for determining the relationship between ID numbers and account numbers. In such a system, the account number and key number are combined using linear and nonlinear operations to generate a check number for comparison with the ID number. The Anderson U.S. Pat. No. 3,956,615 is such a system. For cards issued by different banks to be used in the same terminals, however, all banks must use the same key number, and the account number must be located in the same field on all cards. In one improvement on the Anderson system, a table of encrypted keys is maintained in each terminal, containing the keys required for use in the key-driven algorithm for a plurality of cooperating banks, together with data specifying the location on the card data track of account, offset, and other data to be used in generating the check number for comparison with the ID code entered at the keyboard. In an improvement on that system, which is described in the previously referred to U.S. Pat. No. 4,186,871 of Anderson, et al, the host data processing system includes a virtual financial institution table (VFIT). Upon entry by a consumer of a credit card and personal identification number, the financial institution table (FIT) within the terminal is searched in an attempt to locate an entry corresponding to the institution identified by the credit card. If a corresponding entry is located, data from the fields for that entry is used to encrypt the personal data from the credit card for purposes of verification of the personal identification number entered by the consumer. If a corresponding entry is not located in the financial institution table at the terminal, a search of the virtual financial institution table at the host is made. If a corresponding entry is located in the host financial institution table, the included data is communicated back to the terminal where it is used in the verification of the personal identification number.
Alternatively, the FIT entry at the terminal can include a control bit instructing the terminal to communicate the credit card data and the personal identification number to the host for authorization of the transaction, including the check of correspondence between the account numbers and ID numbers (which is sometimes referred to as a PIN check.)
A PIN check to be performed at the host, in addition to a terminal PIN check, is described in the Anderson U.S. Pat. No. 3,956,615. In such a host PIN check, the personal identification number entered at the terminal is double encrypted and sent to the host, along with card data. At the host, the double encrypted identification number is singly decrypted, and a data base of encrypted identification numbers is accessed by the card data. The encrypted identification number obtained from the data base is compared with the singly decrypted/double encrypted personal identification number received from the terminal to thus perform the host PIN check. However, in this system, it is expected that if the host PIN check fails, the transaction will not be approved--the PIN must be entered correctly on the first attempt.
When the PIN check is performed at the terminal, based upon verification of an algorithmic relationship between card data and the ID number entered at the keyboard, failure of correspondence may result in a request to the individual to try again to enter the correct ID number, and a plurality of failures of correspondence permitted before rejecting the transaction.
While the previously mentioned table derived key-driven credit card and ID number identification technique improves the security of cash issue terminals and permits a plurality of banks to cooperate in honoring cards issued by the others, there are still weaknesses that may be exploited to gain access to the large amounts of cash that are stored in the terminal or available in the accounts of cooperating banks for interfund transfer by operation of the terminal. One serious problem relates to the security of the encryption algorithm for terminals which are capable of stand-alone operation, or even on-line operation. A large number of operators or maintenance personnel are required for the day-to-day support of cash issue terminals. For example, one or two people at each branch bank location may have internal access to the cash issue terminals. Oftentimes these people may have access to the encryption key for normal maintenance. Alternatively, with only a little training, these people could learn to acquire the key by fraudulently tapping the communication line or by measuring electrical signals on the internal circuitry. Once an encryption key is acquired, and if the algorithm is known, a correspondence between a large number of account numbers and ID numbers could be generated. Then, with the knowledge of the card format and location of verification and offset data on the card, correspondence between card data and random chosen ID numbers can be ascertained.
Because of this, some institutions in an interchange environment require that the PIN check be done at their own host so that cooperating banks would never have access to the encryption keys relating the card data to the personal identification numbers. As previously noted, however, this generally requires rejection of a transaction when the host PIN check fails. The customer could immediately try to initiate a second transaction, particularly if told that a PIN check failure caused rejection of the first transaction. However, this is time consuming to the customer and the system, resulting in additional terminal/host communications with resulting expense and degradation of total system availability.